简单暴力！21 分钟学会 apollo-client + redux

apollo-client 是一个比较难用的 GraphQL 客户端，本系列带你集成 redux，趟平深坑，钻入原理，让你在 21 分钟内学完 apollo-client。

NOTE: 阅读过程中如果产生任何不适，请及时拨打 120 自行抢救，谢谢。

本系列的目标：

简单

• 选型建议（是否值得使用 apollo-client）
• 搭建 Apollo client 端，集成 redux
• 使用 apollo-client 来获取数据
• 修改本地的 apollo store 数据

进阶

• 提供定制方案

  • 请求拦截
  • 封装修改 client 的 api
• apollo store 存储细节
• 写入 store 的失败原因分析和解决方案

前置技能

• 了解 React + Redux
• 了解 GraphQL 的基础概念
  对怎么写 Query 等 GraphQL 基础问题不会提及，请查看官方文档Queries and Mutations | GraphQL。

限定提示

• 本方案目前仅使用了 Query 功能，不涉及 Mutation

背景

我司本来采用 RESTful api，但是完全遵循 RESTful 以来，随着业务不断扩展，api endpoint 简直多到爆炸。
对于前端来说，api 太多也难以维护，尤其是设计初期没有提前介入，会导致返回类似的 model，其 Schema 可能不同，这种不一致导致了很多脏代码的产生；
后端也懒于一遍遍地提供类似的接口。

于是，我们就采用了 GraphQL 来解决这个问题。

这里要跟大家明确下我们的项目背景，在采用 GraphQL 前：

• 后端已经基于 RESTful api 搭建了一套很完善的工作流，GraphQL 必须要与 RESTful 共存
• 前端基于 Redux + redux-saga + Immutable.js，并做了不少定制化，引入 GraphQL 必须要与之前的数据存储方案不冲突

后来，后端决定只使用 GraphQL 的 query 功能，也就是只 GET，其它 http 动作仍然走 RESTful api。

如果你的项目是全盘采用 GraphQL 的，下面的实践分享可能不适合你，仅供参考。

client 端选型

GraphQL 总体还是比较前后端分离的，不强制你使用某一种 client 方案。从 awesome-graphql 这个库，进入我们视野的主要有两个

• Relay
• Apollo

Relay

先说说 Relay。
Relay 是官方出品和推荐的，也是默认的配套方案。文档和解决方案更齐全一点。

我粗略扫了一下 Relay 的文档，从它提供的 api 推测，Relay 不仅仅处理 GraphQL，还接管了状态管理等等，理论上用了 Relay 可以不用 Flux 、Redux 了。
考虑到可能和我们现存的 Redux 方案可能冲突，就放弃了。

Apollo

然后是 Apollo。
Apollo 在 github 上 star 也不少，文档乍看也还不错，除 React 外还适配多个框架。
而且有专门提到和 Redux 集成的章节：Integrating with Redux | Apollo React Docs。
时间紧迫，没有想那么多，我就用了（手动捂脸哭）。

事后来看，Apollo 的坑不少。而且最终 Apollo 与其说是和 Redux 集成起来，不如说是隔离开来了，因为 Apollo 也相当于单独维护自己的一个 store。这让我反思是否最初使用 Relay 也会得到同样甚至更好的结果。

不管怎么说，如果你也上了 apollo-client 的贼船，那么希望本系列文章能让你少采一点坑。